…#2 items 1+10) (#7)

Previously the Python entry point `[project.scripts]
template-python-rust-cmd = "template_python_rust_cmd.cli:main"` created
a pip console-script `.exe` that subprocess-launched the staged
`_bin/template-cli`. On Windows that pattern races the next shell
prompt ahead of the child's stdout, because the Python shim returns
to cmd.exe before the spawned native binary finishes flushing. Same
class of bug fbuild fixed in FastLED/fbuild#747.

Drop the shim. ci/build_wheel.py now post-processes the maturin-built
wheel: opens the zip, injects the cargo-built `template-cli[.exe]` at
`<name>-<ver>.data/scripts/template-cli[.exe]`, recomputes the RECORD
row (sha256 + size), and stamps the Unix executable bit on the entry.
Files in `.data/scripts/` are pip's canonical raw-script install
location — pip drops them straight into the venv's `Scripts/` (Win) /
`bin/` (POSIX) directory verbatim, with no Python wrapper for `.exe`
files. Same mechanism cargo-dist and maturin's "bin" mode use.

Removed:
- `[project.scripts]` table from pyproject.toml.
- `src/template_python_rust_cmd/cli.py` (the racy subprocess shim).
- `src/template_python_rust_cmd/_bin/.gitkeep` + the gitignore lines
  that staged binary into the package data directory.
- `action/cleanup/action.yml` step that rm'd the (now-nonexistent)
  `_bin/` staging directory.

Verified end-to-end on Windows:
- Fresh maturin wheel produced via `uv run --no-project --script
  ci/build_wheel.py`.
- `unzip -l dist/*.whl` shows `template_python_rust_cmd-0.1.0.data/
  scripts/template-cli.exe` (1.2 MB) — no `_bin/` entries.
- `uv pip install` of that wheel into a fresh venv lands a `Scripts/
  template-cli.exe` that `file` reports as `PE32+ executable` (NOT a
  Zip-archive console-script stub).
- `cmd /c 'echo === BEFORE === & template-cli.exe --version & echo
  === AFTER ==='` prints `=== AFTER ===` AFTER the version output —
  acceptance criterion from issue #2 met.

The `no-build-isolation-package` setting added in PR #5 was reverted
in this PR: with maturin (vs. setuptools) the trade-off doesn't favor
us — uv reuses a stale build env that lacks maturin, and the preview
`extra-build-dependencies` mechanism is too fragile to ship in a
template. The CARGO_TARGET_DIR pin from that PR stays — it already
gives the cargo-incremental win without touching isolation.

Closes #2 (items 1 + 10).
Refs FastLED/fbuild#747.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Minor bump. Picks up:
- #747 native fbuild as raw wheel script (drops Python launcher; fixes
  Windows stdout-ordering bug on COM25     303A:1001    USB Serial Device (COM25)    ser=80:F1:B2:D1:DF:B1
          └─ Espressif Systems / ESP32-S3 USB-CDC

COM1      [Unknown]
          └─ (no USB identifier — Unknown endpoint)

COM3      [Unknown]
          └─ (no USB identifier — Unknown endpoint)

COM22     303A:1001    USB Serial Device (COM22)    ser=D8:3B:DA:41:64:C0
          └─ Espressif Systems / ESP32-S3 USB-CDC

COM4      [Unknown]
          └─ (no USB identifier — Unknown endpoint)

COM9      303A:1001    USB Serial Device (COM9)    ser=8C:BF:EA:CF:87:B4
          └─ Espressif Systems / ESP32-S3 USB-CDC

COM20     16C0:0483    USB Serial Device (COM20)    ser=15821020
          └─ Van Ooijen Technische Informatica / Teensyduino Serial

COM10     1FC9:0132    USB Serial Device (COM10)    ser=0B03400A
          └─ NXP Semiconductors / LPC-Link2 CMSIS-DAP

5 USB ports, 3 non-USB ports)
- #748 src-layout package-dir (static analyzers resolve fbuild.api)
- #750 daemon WS handler split into reader/writer/inbound
- #751 gitignore .extern-repos/
- #752 cargo fmt + extract test modules so 4 files fall under the
  1000-LOC gate

No public-API changes beyond what's already documented in the merged
PRs above.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>